1. Field of the Invention
This invention relates to an apparatus and/or method for assembling and executing a software computer program representative of a block diagram having none, one or more feedback loops.
2. The Prior Art
Over the past two decades, there has been a growing interest in the use of simulation-based techniques for the analysis and design of signal processor systems, communication systems and control systems. Indeed, a number of systems have been developed for simulation-based analysis to determine performance, criteria and trade-off analysis of proposed systems, Shanmugan et al., "Block-Oriented Systems Simulator (BOSS)," IEEE (1986); Shanmugan, et al., "Computer-Aided Modeling, Analysis and Design of Communication Systems," IEEE, Journal on Selected Issues in Communications, (Jan. 1984).
There are many situations where an explicit performance evaluation of a proposed system cannot be performed without creating an actual prototype. This approach is generally cumbersome, expensive, time-consuming and relatively inflexible; whereas, a computer simulation of the proposed system can be more easily generated and can be used to guide the analysis, testing and documentation of the proposed system.
Simulators are now available for generating models and/or software computer programs for simulating and verifying the performance of prototype or existing systems on a Computer Aided Engineering (CAE) Workstation Platform. A CAE workstation typically includes a programmable microprocessor and a graphics terminal which is a Cathode Ray Tube (CRT) display. The simulators provide the designer with user-friendly environments and easy-to-use design tools for configuring the systems. Typically, a simulator contains four basic components; a system configurator, a function block library, a simulation program builder, and a signal display editor.
The system configurator allows a user to specify the topology of the proposed system in terms of interconnected functional blocks. In some simulators, the system configurator uses interactive graphics, Modestino, et al., "Interactive Simulation of Digital Communication Systems," (Jan. 1984), Wade, et al., "Interactive Communication Systems Simulation Model," (Jan. 1984), while in others, the system configurator uses high level computer oriented software languages, Fashano, "Communication Systems Simulation Using SYSTID," (Jan. 1984), Poza, et al., "A Wideband Datalink Computer Simulation Model," Computers and Electrical Engineering, (1978).
Today, a typical simulator for a workstation platform includes a system configurator called a Block Diagram Editor (BDE). The BDE is a software package which enables a designer to construct a block diagram of the system to be simulated. A high resolution graphics terminal is used to display the block diagram to help the user design, edit, and interact with the block diagram. An extensive library of function block symbols is also provided to enable the designer to pick and choose from existing blocks instead of having to design them on his own.
The library contains information about each block, including its submodules, connections, documentation and high-level program code, all of which can be made available to the designer through on-line windows. Function blocks span a wide range of complexity, starting with "primitive" blocks such as summers, and multiplier blocks to blocks which perform high level functions. The user can connect the blocks together with interconnecting lines and provide required parameter information for each of the blocks. The configuration defined by the designer can then also be used to define a new block which can be stored in the library and which can be later recalled as a single block at a higher level in a hierarchic system design.
Once a block diagram has been defined by the designer the BDE then condenses and represents the block diagram as a network list or "netlist". The netlist is a computer-readable form of the block diagram, containing all the required information about the block diagram, such as how the blocks are connected together, the software procedure call the block represents, parameter lists, etc. The simulator converts the netlist version of the block diagram into a high-level computer program by use of a Simulation Program Builder (SPB). The high level computer program is essentially a model of the proposed system which had been previously described by the block diagram.
The high-level code can then be executed to perform and display a simulation of the block diagram. Typically, the simulation will be carried out without any user intervention. During the simulation execution, selected signal values can be collected and saved in various signal files. These signal files can then be accessed by a Signal Display Editor (SDE) that allows the designer to generate, manipulate and analyze the signals.
The signal display editor uses a variety of signal plotting and processing techniques to analyze the results of a simulation. The designer can select from a variety of commands, such as selecting a portion of a signal and displaying it as a function of time and performing spectral analysis.
Simulators are known which have the capability of simulating block diagrams representative of systems which have "feedback." Feedback is the reversion of the output of a system or process to a preceding stage in the same system or process for the purpose of allowing the system or process to perform self-correcting actions based on its output.
One example of a system having feedback is a simple signal processing filter which requires continuous evaluation of the output of the filter in order to determine which corrective measures to take. Systems having feedback are not limited to the signal processing environment. Indeed, any system having self-correcting type measures needs to be designed and modeled with some form of feedback arrangement. Present simulators do not have the capability of adequately simulating systems with feedback because they inefficiently model and simulate blocks in a feedback environment which have a "delay" property; the delay property requires the blocks to have a "state." A "state" is a predefined vector of parameters which are called state variables. State variables are defined by the following conditions:
1) For any time, say T.sub.1 (time), the state at T.sub.1 (that is the state variables) and the input waveforms determine uniquely the state at any time T&gt;T.sub.1 ; and
2) the state at any time T and the inputs at any time T determine uniquely the output value at time T of the block. Desoer et al., Basic Circuit Theory 198, 508 (1969). Essentially, "state" enables a block to process and generate defined outputs without having to have defined inputs. The principal of "delay" comes from the fact that the input values are not immediately required to process the function of the block in order to produce defined information. These concepts are discussed in greater detail in the Detailed Description portion of this application.
One such example of a present simulator which inefficiently models and simulates block diagrams having feedback loops is described in an article by David G. Messerschmitt entitled, "A Tool for Structured Functional Simulation," IEEE Journal, Selected Areas On Communication, Vol. SAC-2, No. 1, (Jan. 1984). In this article, a system called "BLOSIM," for simulating block diagrams, is described. In order to accommodate for the "delay" property of blocks which occur in feedback loops, the BLOSIM system provides a buffering type system for ensuring proper synchronization of the delay blocks. More particularly, for each delay block there is provided an input "FIFO" (first-in, first-out) buffer and an output FIFO buffer. The BLOSIM system provides a single software procedure representative of each delay block. The software procedure contains conditional statements for evaluating the status of the buffers. These statements are executed during the simulation of the block diagram in order to determine when particular portions of the routine representative of the delay block need to be performed.
Additionally, to improve efficiency, a sequencer routine presequences the software procedures for the blocks such that they are executed in the order of "signal flow," which is determined by the particular topology of interconnections of the blocks in the block diagram. The presequencing procedure alone, however, will not correctly sequence the software procedures representative of block diagrams which have one or more feedback loops. By repeatedly executing the software procedures in the order determined by the presequencing operation, BLOSIM provides available samples to the input FIFO buffers. When the output FIFO buffer for a particular delay block is not full and the input FIFO buffer is not empty, the software procedure representative of the block removes an input value from the input FIFO buffer and directs the necessary operations representative of the block. Outputs are provided to the output FIFO buffer for the corresponding block until the output FIFO buffer is full. The simulation "deadlocks" (terminates) when each software procedure representative of the block does not attempt to access a FIFO buffer or has an empty input FIFO buffer or a full output FIFO buffer, see, Messerschmitt, "BLOSIM, A Block Simulator," Version 1.1, University of California, Berkeley, internal memo (Jun. 7, 1982).
The BLOSIM simulator uses inefficient software programs and as a result causes inefficient execution because parts of the program are repetitively executed until each block has an empty input FIFO buffer or a full output FIFO buffer or does not attempt to access a FIFO buffer. Additionally, each software program representative of a delay block contains at least one conditional statement which is repetitively executed in order to determine when the input FIFO buffer is empty and/or when the output buffer is full. During simulation, such re-execution of the program slows down simulation. Furthermore, BLOSIM does not organize or sequence the procedures for storage so that the procedures can later be loaded into the memory of a chip for control of that chip.
U.S. Pat. No. 4,677,587 to Zemany discloses a simulator for generating a computer program representative of a block diagram having one or more feedback loops. Specifically, the system forms a table into which the user inserts block identifiers for each block of the block diagram. The user also specifies each block's interconnections with the other blocks of the block diagram. The information for each block is entered into the table in the order that they appear, from left to right, in the block diagram, except for blocks having a delay property which are entered last. The system provides a test function for ensuring that the block identifiers and interconnections have been entered by the operator in the proper order.
The Zemany simulator inefficiently constructs a computer program representative of a block diagram because the user of the system must construct a table of procedure calls representative of the block diagram. When the block diagram is complex, the operator's task becomes very time consuming and cumbersome. In sum, the simulator disclosed by Zemany is an unautomated workstation for assisting the user in designing computer programs representative of block diagrams.
Another example of a present simulator which inefficiently models block diagrams having one or more feedback loops is described in a user's manual entitled, "BOSS (Block Oriented Systems Simulator)," University of Kansas and TRW, BOSS version: Star 1.1 (1986). In this manual, a system called "BOSS," for simulating block diagrams is described. In order to accommodate blocks which have delay property, the BOSS system provides specific delay elements which must be present in the simulation. The BOSS system does not provide a mechanism for allowing a user of the system to design and identify his own blocks which have a delay property. For this reason, the user's task of designing systems which have feedback loops can become cumbersome because the user is constrained to use only the delay elements provided by the system.